[Critical] R3-1: (fix-induced) [certifies-falsely] [new-surface] The round-3 fix for R3-1 gated the /cd process.env rewrite on ownsProcessEnvironment: () => this.sessions.size <= 1, but the predicate counts only STORED sessions. A session mid-creation is invisible in this.sessions until createAndStoreSession stores it AFTER the awaited llmClient.initialize() (acpAgent.ts:12935), and initializingConfigs is only populated when chatRecording !== false — so a /cd committed while a sibling session/new is in flight still rewrites process.env.

An ACP child hosts session A; the host issues session/new for B, whose creation awaits llmClient.initialize() (auth + MCP startup — seconds). The host issues session/cd for A inside that window: ownsProcessEnvironment() reads sessions.size === 1 → true → commit() applies A's target-project env to process.env and strips the previous project's file-sourced keys. B's own env keys (applied at its session/new start) are wiped and never re-applied, and every MCP server and shell tool B spawns afterwards inherits A's project environment — the exact cross-session leakage this gate exists to prevent. Re-evaluating the predicate at commit time does not close this: an unstored creation is invisible at any evaluation point.

Witness:

witness: not run — closest capability was an interleaving probe in the acpAgent.test.ts harness (stall session B inside llmClient.initialize, issue qwen/control/session/cd for A, assert the env rewrite ran); not seeded because it requires the full ACP connection + session-lifecycle mock scaffolding, while the guard's blindness is a static fact — the closure reads this.sessions.size only, and sessions.set is structurally after the awaited init.

Fix: count in-flight creations in the predicate — increment a pending-creation counter at newSessionConfig entry, decrement it on store and on every failure path, and use this.sessions.size + pendingSessionCreations <= 1. initializingConfigs alone cannot serve as that counter (acpAgent.ts:12621-12622 — populated only when chatRecording !== false).

Fix witness: in acpAgent.test.ts, hold a creation in flight (mock llmClient.initialize with a deferred promise), start session/new, capture the host-policy argument passed to loadCliConfig and assert ownsProcessEnvironment() returns false — removing the in-flight count must turn it red.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Critical] R4-17: [certifies-falsely] [regression] reloadForProjectChange() unconditionally clears the AUTO-mode dangerous-rule stash and relies on initialize() to re-strip, but initialize() only re-strips when the BASE config's approval mode is 'auto' (permission-manager.ts:231-233; the PM's config is the base Config — config.ts:3567). A strip acquired by a subagent's AUTO override (InProcessBackend.acquireAutoApprovalOverride, InProcessBackend.ts:522) while the base session stays non-AUTO is silently dropped by /cd, re-activating the dangerous allow rules under the still-running AUTO subagent. On agent exit restoreDangerousRules() is a no-op (stash undefined), so the lost state is never repaired. Pre-diff, nothing except the paired restoreDangerousRules ever cleared the stash.

Concrete shape: trusted folder; base session in DEFAULT mode with a dangerous allow rule (Bash); an AUTO subagent runs with the strip active. The user /cds → the stash is cleared, initialize() sees base mode ≠ 'auto' → no re-strip. The AUTO agent now gets 'allow' for everything the broad rule matches, bypassing the AUTO classifier/manual review for the rest of its run (shouldForceAutoModeReviewForAllow only intercepts protected-write paths).

Witness:

probe (real PermissionManager, base mode 'default', rule Bash):
PR code:  stash after reload: undefined / decision after reload: allow / decision after agent exit: allow
with fix: stash after reload: {persistent:[Bash],session:[]} / decision after reload: ask / decision after agent exit: allow

Fix:

const wasStripped = this.strippedAllowRules !== undefined;
// ... existing restore + reset + initialize() ...
if (wasStripped && !this.strippedAllowRules) {
  this.stripDangerousRulesForAutoMode();
}

The re-strip must leave the stash defined so release-time restore still works: stripDangerousRulesForAutoMode early-returns when already defined (permission-manager.ts:1449-1451), and releaseAutoApprovalOverride restores only when base mode is not AUTO (InProcessBackend.ts:541-545).

Fix witness: permission-manager.test.ts — config with approvalMode: 'default' and permissionsAllow: ['Bash']; initialize(); stripDangerousRulesForAutoMode(); reloadForProjectChange(); assert the stash is still defined and the dangerous command does not evaluate to 'allow'. Removing the re-strip guard turns it red.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Critical] R4-22: [certifies-falsely] [new-surface] prepare() resolves webSearch against the OLD project's process.env: resolveWebSearchSettings reads ENABLE_WEB_SEARCH/WEB_SEARCH_MODEL/WEB_SEARCH_EXTRACTOR/WEB_SEARCH_BASE_URL/WEB_SEARCH_API_KEY from process.env (cli config.ts:1030-1043), but the target's env only reaches process.env later, in commit()'s reloadEnvironment. The sibling resolveDisabledSlashCommands is explicitly passed targetEnvironment for exactly this reason (config.ts:1555-1561); webSearch is not.

Session in project A whose .env sets WEB_SEARCH_BASE_URL=https://a.example/search; /cd to project B whose .env sets its own base URL and WEB_SEARCH_API_KEY=key-B. prepare() snapshots A's baseUrl into the config; commit() rewrites process.env to B's values; at call time the web-search tool sends the request to the captured baseUrl with the bearer key read live from process.env (web-search.ts:220-221) — B's API key is transmitted to A's endpoint. Inverse: A's ENABLE_WEB_SEARCH=false keeps web search disabled after /cd into a B that enables it; in a shared process (ownsProcessEnvironment false) the host daemon's env is consulted instead of the computed target view.

Witness:

probe (real reloader, real .env files):
after prepare(projectB): webSearch = { enabled: true, baseUrl: 'https://a.example/search' }
after commit():          process.env.WEB_SEARCH_BASE_URL = 'https://b.example/search'
with fix (env param fed targetEnvironment): baseUrl becomes 'https://b.example/search'; inverse arm flips to enabled true; shared-process arm resolves the target view

Add an env: Readonly<NodeJS.ProcessEnv> = process.env parameter to resolveWebSearchSettings (same shape as resolveDisabledSlashCommands) and pass targetEnvironment here. The API key itself is read at invocation time from process.env[apiKeyEnv] (packages/core/src/tools/web-search.ts:221), so only the env var NAME and literal values (baseUrl, model, enabled) may be captured from the target view.

Fix witness: a case in config.projectRuntimeReloader.test.ts that puts WEB_SEARCH_BASE_URL values into process.env differing from the target's env view and asserts prepared.config.webSearch.baseUrl equals the target view; removing the new env argument keeps the suite green and reddens this test.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Critical] R4-23: [fails-closed] [regression] In bare mode nextSettings is createMinimalSettings(), which hardcodes isTrusted: false (settings.ts:698-716), so an unconfirmed /cd in a bare session flips Config.trustedFolder from true to false. Startup computes isWorkspaceTrusted(settings)?.isTrusted ?? true (cli config.ts:1986), which returns { isTrusted: true } when folder trust is disabled (trustedFolders.ts:410-417) — bare sessions START trusted.

qwen --bare interactive session; /cd ../other. cdCommand skips the trust branch (isFolderTrustEnabled({}) is false) and passes no trustedFolder, so prepare() computes effectiveTrust = undefined ?? false = false and applyProjectRuntimeConfig installs it. From then on setApprovalMode(AUTO|AUTO_EDIT|YOLO) throws TrustGateError (core config.ts:7479-7484) — a session that started trusted and could switch modes before the move cannot after it, with no UI path to re-trust the folder (folder trust is disabled in bare mode), and getTrustedDerivedApprovalMode silently downgrades derived/subagent configs.

Witness:

probe:
isWorkspaceTrusted(createMinimalSettings().merged)?.isTrusted ?? true === true   (startup)
prepared.config.trustedFolder === false                                          (bare prepare, no trustedFolder arg)
createMinimalSettings().isTrusted === false
with fix: prepared.config.trustedFolder === true

An explicit confirmation must still win — cdCommand passes { trustedFolder: true } only after the confirm round-trip.

Fix witness: a bare-mode case in config.projectRuntimeReloader.test.ts asserting prepared.config.trustedFolder === true from prepare(targetDir) with no trustedFolder argument; reverting to trustedFolder ?? nextSettings.isTrusted reddens it.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Critical] R4-24: [certifies-falsely] [new-surface] After a readOnly /cd load (migration in memory, disk left legacy by design), the first workspace-scope setValue patches the still-legacy disk file in MERGE mode (updateSettingsFilePreservingFormat preserves keys not in updates), and this hot-reload migration branch then resolves the resulting legacy+nested collision in favor of the LEGACY value — silently reverting the user's write.

/cd into a project whose .qwen/settings.json is V1-shaped {"theme": "dark"}; the readOnly load migrates in memory and the disk stays legacy. The user changes theme to light: setValue → saveSettings deep-merges into the disk file, keeping the legacy top-level key ({"theme":"dark","ui":{"theme":"light"}}). The watcher fires and reloadScopeFromDisk(Workspace) hits this branch; v1→v2 writes the legacy value into ui.theme first (v1-to-v2.ts:162-191) and skips the colliding nested child via wasProcessed (v1-to-v2.ts:225-247), so ui.theme resolves to legacy 'dark' — the user's 'light' is silently dropped ~300ms after they set it. On the next startup the same migration persists the reverted value permanently. Pre-diff this could not occur: a project's settings file was always migrated on disk at first load.

Witness:

probe (real code):
disk starts {"theme":"dark"}; readOnly load → merged.ui.theme 'dark', migratedInMemoryScopes.has(Workspace) true
setValue(Workspace,'ui.theme','light') → disk {"theme":"dark","ui":{"theme":"light"}}
reloadScopeFromDisk(Workspace) → merged.ui.theme === 'dark'   ← user's 'light' silently dropped
removing the migration branch → merged.ui.theme stays 'light' (branch is load-bearing for the revert)

Fix: persist the in-memory migration once the relocation is committed — in the reloader's commit()/complete(), write file.originalSettings for each scope in migratedInMemoryScopes via a sync-mode updateSettingsFilePreservingFormat (or make the first post-/cd write of such a scope a sync-mode write of the full migrated object) — so legacy keys never coexist with their migrated counterparts on disk. The persist belongs at/after commit, never inside the readOnly load (the no-write-before-commit contract stated by settings.project-runtime.test.ts:98-100).

Fix witness: settings.project-runtime.test.ts — readOnly-load legacy {"theme":"dark"}, replaceWith, run the post-commit persist step, setValue(Workspace,'ui.theme','light'), reloadScopeFromDisk(Workspace), assert merged.ui?.theme === 'light'; removing the persist step reddens it.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Suggestion] R4-4: contextFileNamesForCwd normalizes both sides with path.resolve only, but after /cd the session's stored working directory is a REALPATH (core config.ts stores expectedCanonicalDir ?? fs.realpathSync(targetPath)), while the host-supplied param is not — so a symlinked (or case-folded) spelling of the very same directory misses every session and falls through to the stale process-global filename list. This is a sibling corner of the fixed R2-2 (the trailing-slash/raw-spelling case, closed by path.resolve in 1da1167).

A session /cds into /tmp/proj; core stores /private/tmp/proj (macOS realpath). The host calls qwen/settings/getMemoryPaths with cwd: '/tmp/proj': path.resolve('/tmp/proj') !== '/private/tmp/proj' → no session matches → the fallback getAllMemoryFilenames() returns the process-global list; the host gets QWEN.md paths for a project whose session loaded CONTEXT.md, and the host's memory editor reads/writes a file the session never loads, silently discarding user edits.

Witness:

probe (real symlink in the acpAgent.test.ts harness, session getWorkingDir() = realpath, host request via the link spelling):
PR code: PROJECT-MEMORY-FILE = <link>/QWEN.md   ← global fallback, not the session's CONTEXT.md
with realpath canonicalization of both sides: PROJECT-MEMORY-FILE = <link>/CONTEXT.md (and the trailing-slash case still passes)

Fix: canonicalize both sides with realpath before comparing, e.g.

const canonical = (p: string): string => {
  try {
    return fs.realpathSync(p);
  } catch {
    return path.resolve(p);
  }
};

and compare canonical(config.getWorkingDir()) === canonical(cwd). Both sides must be canonicalized: a session that never /cd-ed stores a resolved-but-not-realpathed directory (see the comment above this block), so realpathing only the requested side would break the construction-time match.

Fix witness: extend the scoped-session case in acpAgent.test.ts (~12252): create a symlink to the real directory, have the fake session's getWorkingDir() return the realpath, query getMemoryPaths with the link spelling, and assert CONTEXT.md is returned; removing the realpath normalization reddens it.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Suggestion] R4-6: the cross-session env-leak guard ownsProcessEnvironment: () => this.sessions.size <= 1 is wired with NO test anywhere exercising the predicate (zero ownsProcessEnvironment references in acpAgent.test.ts). The reloader-level tests supply () => false directly, so mutating the agent wiring — or dropping the field entirely, which the reloader defaults to true (cli config.ts:1511) — ships with a fully green suite.

Mutation <= 1 → true: an ACP child hosting two live sessions; session 1 /cds and rewrites process.env; session 2's subsequently spawned MCP servers and shell tools inherit session 1's project secrets and lose session 2's own env keys — exactly the leak the predicate exists to prevent.

Witness:

probe: mutate the wiring to ownsProcessEnvironment: () => true, run acpAgent.test.ts
junit: tests="517" failures="0" errors="0"   (baseline also 517/517 — the mutation survives)

Fix: capture the loadCliConfig host-policy argument in an acpAgent relocation/host-policy test and assert ownsProcessEnvironment() is true with one live session and false once a second entry is added to agent.sessions. The test goes red if <= 1 becomes <= 0, >= 1, or true. (Pairs with the R3-1 fix above, whose own witness covers the in-flight-creation arm.)

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Suggestion] R4-14: the effect cleanup's freedom from a duplicate "loops cancelled" notice depends on relocateWorkingDirectory destroying the scheduler BEFORE committing the new working directory (core config.ts:6071-6075), and no test pins that ordering. The new cron-restart test mocks getExitSummary: () => null, so the cleanup's stderr write can never fire there; core tests pin only cronExitSummary capture.

Mutation: move this.cronScheduler?.destroy() past the commit point (e.g. below await refreshCurrentRuntimeStatus). The post-/cd re-render's cleanup then reads a non-null getExitSummary() from the not-yet-destroyed scheduler and process.stderr.writes the raw multi-line cancellation notice into the Ink-rendered TUI, while cdCommand simultaneously surfaces the same text via formatCronRelocationNotice — duplicated, UI-garbling output. Every existing test stays green.

Witness:

witness: not run — closest capability was a mutation probe moving cronScheduler.destroy() past the commit point and driving the cron-effect harness with a non-null exit summary; not run because the existing effect harness mocks getExitSummary: () => null by construction (a new effect-level fixture would be required) — the substance (no test pins the ordering/silence) is settled by the test inventory above.

Fix: add a relocation test that exercises the real ordering — give the old scheduler a session-only job, run relocateWorkingDirectory, and assert the exit summary surfaces exactly once (via the returned cronExitSummary) and the effect cleanup's stderr path stays silent. The summary must stay captured before destroy() clears jobs/wakeups (cronScheduler.ts:1623); reordering destroy after the cwd commit must turn the test red.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Suggestion] R4-28: complete()'s appEvents.emit(AppEvent.McpPendingApprovalChanged) (cli config.ts:1845-1849) is unwitnessed: this doubled-complete test calls complete() twice without spying on appEvents.emit, while the rollback twin's emission IS asserted in the swap test (line 390); the only test reaching committed complete() has no emit spy.

Delete the appEvents.emit(…) line from complete() and the entire suite stays green; after a successful /cd the target project's pending MCP approval gating (assembled in prepare) is never re-signaled to the UI, which keeps showing the previous project's approval state until an unrelated event fires.

Witness:

probe:
mutant deleting the emit from complete() → Tests 16 passed (16)   (mutation invisible)
mutant + suggested spy/assertion        → 1 failed
intact code + assertion                 → Tests 16 passed (16)

Fix: in 'resumes the watcher exactly once when the switch completes', vi.spyOn(appEvents, 'emit') and assert it was called with AppEvent.McpPendingApprovalChanged after complete(), mirroring the rollback assertion in the swap test. Removing the emit from complete() makes the new assertion red.

— qwen3.8-max via Qwen Code /review (v0.22.3)

[Suggestion] R4-30: the /cd wiring of maxConcurrentBackgroundAgentsByModel is unwitnessed: applyProjectRuntimeConfig passes both caps (core config.ts:5804-5808), but the relocation test asserts only the global cap (config.test.ts:7988-8022); the by-model startup describe goes through the constructor and the registry-level tests call setConcurrencyLimits directly. normalizePerModelConcurrency(undefined) returns an empty map, so dropping the line is invisible.

Delete the maxConcurrentBackgroundAgentsByModel line from applyProjectRuntimeConfig: setConcurrencyLimits receives undefined, the per-model map becomes empty, and the entire suite stays green — /cd into a project configuring agents.maxParallelAgentsByModel then silently enforces NO per-model throttling (a model capped at 1 can spawn unbounded background agents), diverging from a fresh session in the same project.

Witness:

probe:
baseline over config.test.ts + background-tasks.test.ts → Tests 743 passed (743)
mutant deleting the byModel line                        → Tests 743 passed (743)   (invisible)
mutant + suggested relocation extension                 → expected true to be false
intact code + extension                                 → 1 passed

Fix: extend 'relocateWorkingDirectory updates agent, worktree, and persistence runtime state' to prepare the target with agents: { maxParallelAgents: 3, maxParallelAgentsByModel: { 'weak-model': 1 } }, register one running weak-model agent, and assert canStartBackgroundAgent('weak-model') is false after relocation. Removing the byModel wiring line reddens it.

— qwen3.8-max via Qwen Code /review (v0.22.3)